今天讓我們來談談關於 版本控制 充個天數。

Git 幾乎是現在軟體用來做版本控制的主流，而本篇當然還是因為跟 TDD 有關，至於 Git 的好處及如何使用，應該能輕鬆找到非常多的教學資源。

Commit

在 Git 中每一個版本被稱為一個 commit，每當我們對程式碼做了一些更新時，我們會將這次新增與修改的檔案加入新的一次 commit。

然而多少新的程式碼，應該被稱作一個「新的版本」？何時要產生一個「新的 Commit」，這是一件模糊的事情。

Commit Message

每次送出 Commit 時，Git 會要求輸入一段文字，稱為 commit message。

commit message 可以讓人快速瀏覽以前的版本紀錄，如果寫得太模糊不清，那我們要回去查看程式碼的版本，是在哪一個 commit 裡。

因此有人對於 commit message 提出了七個規範 How to Write a Git Commit Message，想要看中文翻譯的也可以參考這篇。

其中第二點如下：

限制標題最多只有 50 字元。

目的是為了 git log 顯示時，可以一次看到完整的 commit message，超過50字的部分會表示成 ...，例：「Add a new fifty-word func...」。

頻率

為了讓 commit message 不會太長，因此更新的程式碼要嘛是沒有很多，要嘛就是容易描述的同一功能，這樣後續比較容易追查版本，進行版本控制才有意義。

因此要避免一次 commit 太多內容，當然太過繁瑣的 commit 同樣也會造成困擾。

回到 TDD 的使用，TDD 會漸進式的一步一步產生程式碼，每次循環都會產生出可執行的程式碼跟測試，如果一次循環就送交一次 commit 也許又太頻繁，可以經過幾個紅綠燈循環、完成一小組較緊密的功能後，再送交一次 commit。

先思考要做哪些 Commit

可以試著在開始 Coding 之前，就先構思要完成哪些部分，總共多少功能、哪些 commit，把每個 commit 預計的 commit message 寫下來，之後才開始寫 code，即使不是 TDD 同樣也能這麼做。

整理 commit 們

如果寫完一大段之後，才發現自己的 commit 太繁瑣零碎了，也可以回去整理自己的 commit，將多個 commit 合成一個，可以參考 【狀況題】把多個 Commit 合併成一個 Commit，不過如果是多人協作請記得不要修改已經 push 上去的部分。

TDD 與版本控制

TDD 時搭配使用著 Git 做版本控制，當測試或產品程式沒寫好、想要倒回去到前一些些的版本時，就相當容易，學 TDD 時順便學個 Git 絕對也是不虧的。